You must assign user and group accounts to SharePoint groups or permission levels to grant site access to those users. Users who can access a site can also perform reporting tasks. For example, users with view permissions to access a site can also view reports on that site.

To complete the integration steps, you must ensure that all users who access and manage report server content on a SharePoint Web application have the appropriate permissions. You might also want to add Reporting Services content types so that users who have permission to use Report Builder can start it from the New menu. To add content types:

1. Open the library for which you want to add Reporting Services content types.
   
   
2. On the Settings menu, click Document Library Settings.
   
   
3. Under Content Types, click Add from existing site content types. If Content Types is not available, locate the General Settings section and click Advanced settings to allow content type management.
   
   
4. In the Content Types section, select Yes to allow multiple content types.
   
   
5. In the Select Content Types section, in Select Site content types from list, click the arrow to select Reporting Services.
   
   
6. In the Available Site Content Types list, click Report Builder Report, and then click Add to move the selected content type to the Content types to add list.
   
   
7. To add Report Model and Report Data Source content types, repeat steps 5 and 6.
   
   
8. When you finish selecting all the content types that you want to add, click OK.
   
   

Verify integration by starting the Reporting Services Configuration tool and opening the SharePoint Integration page to view server status. You should see a link that you can click to start SharePoint Central Administration.

You can also verify an installation by opening a browser window and entering a URL to the report server. The URL should resemble http://example-server-name/reportserver.

Finally, you should be able to navigate to a library in the SharePoint site and upload report definition (.rdl) files and report model (.smdl) files. Make sure that the data source properties for the report are correct. The data source must have a valid connection string to an external data source. The credential type must be valid for your network topology. Specifically, if Kerberos authentication is not enabled for your domain, you cannot use the Windows integrated security credential type if the report server is on a different computer. Instead, you should specify stored credentials. After you verify that the data source properties are correct, you can click the report name to open the report. The report will open in the Report Viewer Web Part automatically.

[Top]

There are no plans to support the following SharePoint technology features for items that are processed on a Reporting Services report server:

• Outlook Calendar integration for scheduled report server operations. You cannot use Outlook Calendar to schedule data or subscription processing on a report server.
  
  
• Personalization features are not supported for the Report Viewer Web Part. Date, time, and currencies must be specified in the formats that are defined at the site level.
  
  
• Anonymous access cannot be enabled for the SharePoint Web application.
  
  

There are no plans to support the following features on a report server that runs in SharePoint integrated mode:

• Report Manager or SQL Server Management Studio. All server management is performed through the Reporting Services Configuration tool and SharePoint Central Administration.
  
  
• The Reporting Services role-based authorization model that includes predefined roles such as Browser, Content Manager, and Publisher. A report server that is configured for SharePoint integration always uses SharePoint permissions and groups to control access to report server content and operations.
  
  
• Custom security extensions. A report server that runs in SharePoint integrated mode uses a modified version of the default security extension; you cannot use the Reporting Services custom authentication features in a report server that runs in SharePoint integrated mode.
  
  
• Migrating report server content between report server databases that are configured for different modes. The content that is stored in each database type contains permissions and addresses that are not valid in a different mode.
  
  
• Linked reports will not be supported.
  
  
• Data-driven subscriptions will not be supported.
  
  
• The Manage Jobs pages and API used to stop an ongoing report execution process will not be supported.
  
  
• Batching methods will not be supported.
  
  
• My Reports will not be supported.
  
  

[Top]

For a report server that runs in SharePoint integrated mode, you might encounter an ASP.NET time-out error for long-running reports that require more processing time than the default time-out specifies. By default, the ASP.NET time-out is approximately two minutes. Reports that need more than two minutes to process will quit unexpectedly and the Windows SharePoint Services error page will appear with the following error: “An unexpected error has occurred.”

If you think this error is due to a time-out issue, you can work around the error by adding an httpRuntime executionTimeout attribute to the Web.config file of the SharePoint Web application.

Be sure to provide a value that is sufficient to complete processing for long-running reports. For a native mode report server, the default value is 9000 seconds for a report server and Report Manager. Consider choosing a similar value when you specify executionTimeout for the SharePoint Web application.

If you have deployed multiple applications in a SharePoint farm, repeat the previous steps for each Web.config file in the farm. This requirement applies to all the SharePoint Web application Web.config files in the subdirectories under <drive>:\inetpub\wwwroot\wss\VirtualDirectories. It also applies to Web.config files for applications in the farm that are installed on different computers.

[Top]

When you specify a report server URL in the Manage integration settings page in SharePoint 3.0 Central Administration, do not use http://locahost/reportserver for the report server URL if the report server is integrated with SharePoint Web applications that are part of a farm deployment. A URL address that specifies http://localhost will not be valid for SharePoint Web front-ends that are installed on remote servers.

[Top]

A deployment of a SharePoint product or technology uses a variety of accounts to run services and access front-end and back-end servers. If you specify domain accounts for your deployment, be sure to follow best practice recommendations and specify accounts that are used exclusively by the SharePoint Web application. Do not configure a service account to run under the domain user account of an actual person who will be accessing the SharePoint site. If you access a SharePoint site using service credentials, you might encounter access denied errors when you open reports.

If you do not use a domain account, you might encounter a second issue if you have the following combination of factors:

• The report server is integrated with a SharePoint farm that consists of more than one computer.
  
  
• The SharePoint site and the report server are on different computers.
  
  
• The SharePoint site is hosted in an application pool that runs as a built-in account, such as NetworkService.
  
  
• The Reporting Services proxy endpoint connection to the report server is configured to use Trusted Account mode.
  
  

In this scenario, when a user views a report or accesses Reporting Services features from the SharePoint site, the following error occurs:

"An unexpected error occurred while connecting to the report server. Verify that the report server is available and configured for SharePoint integrated mode. The permissions granted to user '<acccountname>' are insufficient for performing this operation."

To avoid this error, follow the recommendations in the Windows SharePoint Services 3.0 product documentation and run the application pool service as a domain account. For more information about service account requirements and recommendations, see Plan for administrative and service accounts in the Windows SharePoint Services 3.0 product documentation.

[Top]

Restrictions on using built-in accounts apply to some deployment topologies of Reporting Services that include a report server running in SharePoint integrated mode. The following combination of factors will result in service account requirements:

• The report server is integrated with a SharePoint farm comprising more than one computer.
  
  
• The report server and SharePoint Central Administration Web site run on separate computers.
  
  

In this scenario, if either the Report Server Web service or Windows service runs under a built-in account such as NetworkService, the Grant database access option in SharePoint Central Administration will not work correctly. Consequently, accessing any Reporting Services feature through a SharePoint site will result in the following error:

"An unexpected error occurred while connecting to the report server. Verify that the report server is available and configured for SharePoint integrated mode. --> Server was unable to process request. --> Client found response content type of 'text/html; charset=utf-8', but expected 'text.xml'."

To avoid this error, choose one of the following approaches:

• On the computer that hosts the report server, continue to run the Report Server Web service as NetworkService and add the built-in account, such as NT_AUTHORITY\NetworkService to the WSS_WPG Windows group.
  
  
• Configure the service accounts to run under a domain user account as follows:
  
  
  1. Start the Reporting Services Configuration tool and connect to the report server.
     
     
  2. Click Windows Service Identity, click Windows Account, type a domain user account, and click Apply.
     
     
  3. Click Web Service Identity, for Report Server, click New, type an application pool name, click Windows Account, type a domain user account, and click Apply.
     
     
  4. Reset IIS.
     
     
  5. Restart the Windows service.
     
     

[Top]

If you installed a previous Customer Technical Preview (CTP) release of the Reporting Services Add-in, you might encounter server or configuration errors when installing a newer version. The ReportServer.resx file is not removed when you uninstall a CTP, causing the error "The namespace 'Resources' already contains a definition for 'ReportServer'" to occur when you install a newer version. To work around this error, delete ReportServer<cultureID>.resx from the \inetpub\wwwroot\wss\virtualdirectories\<portnumber>\App_globalresources folder, and then re-run Setup for the Reporting Services Add-in.

If you installed a previous release, you must uninstall it before you can install a newer version. There is no upgrade support for previous versions of the add-in.

[Top]

When you subscribe to a report, one of the selections for Delivery Type is Null Delivery Provider. This delivery type is not supported for individual subscriptions that you create from a SharePoint site. To remove it from the list of available values, you can edit the RSReportServer.config file on the report server computer to hide the delivery type from the application pages.

1. Open RSReportServer.config file in a text editor.
   
   
2. Replace this entry:
   
   

   <Extension Name="NULL" Type="Microsoft.ReportingServices.NullDeliveryProvider.NullProvider,ReportingServicesNullDeliveryProvider"/>

   With this one:
   
   

   <Extension Name="NULL" Visible="False" Type="Microsoft.ReportingServices.NullDeliveryProvider.NullProvider,ReportingServicesNullDeliveryProvider"/>

[Top]

The online help states that the "Use Remote Interfaces" permission is not used. This statement is incorrect. The permission is actually required for report server access. If you are using the predefined permission levels (such as Full Control, Contribute, or Visitor), the permission is already included. If you are creating custom permission levels, be sure to include "Use Remote Interfaces" in the permission level you create.

[Top]

When you use custom permission settings to access reports and other items that process on a report server, you must include the "Browse User Information" permission to allow the following operations:

• Browse for reports and other items across different sites, libraries, and folders.
  
  
• Publish reports and other items to a library.
  
  

The "Browse User Information" permission allows the report server to return information about the creator of the item and the user who last modified the item. Without this permission, the report server will return the following errors:

• For browse operations, the error is: “Report Server has encountered a SharePoint error. ---> System.UnauthorizedAccessException: Access is denied.”
  
  
• For publish operations, the error is: “The permissions granted to user ‘<domain>\<user>' are insufficient for performing this operation.”
  
  

If you are using predefined permission levels, no action is required because “Browse User Information” is already included in Full Control, Design, Contribute, Read, and Limited Access. However, if you are using custom permission levels or editing the permissions assigned to a particular user or group, you must add the permission manually.

[Top]

Some permissions have dependencies on other permissions (for example, "Add Items" depends on "View Items" and cannot be used effectively unless "View Items" is also in the same permission level). Permission dependencies introduce requirements on how you specify permissions. If you set permissions from the application pages, all dependent permissions are selected for you automatically. However, if you set permissions programmatically, you must add any dependent permissions yourself. For a complete list of permission dependencies, see the help article "Permission levels and permissions" in the online help of your SharePoint site.

[Top]

You can control access to specific entities and perspectives in a model by setting permissions on the item hierarchy within the model. To set permissions within a model, you must have "Manage Permissions" permission, which is a site level permission that is granted to site owners and other SharePoint groups who have Full Control level of permission. If you want to offer specific users the ability to set model item security, you must break permission inheritance and grant elevated permissions (such as Full Control, which includes the Manage Permissions permission) on the model file. When you grant Full Control on an item in a library, the permissions are scoped to that item and do not extend to the parent or to other items within the same library. After the user has Manage Permissions on the model, he or she can set model item security via the SharePoint site.

To configure Full control permission level on a model (.smdl) file, do the following:

1. Log in to the SharePoint site using an account that has Manage Permissions on the site.
   
   
2. Open the library that contains the model.
   
   
3. Point to the model.
   
   
4. Click the down arrow next to the model, and click Manage Permissions.
   
   
5. Click Actions.
   
   
6. Click Edit Permissions. Click OK.
   
   
7. Click New.
   
   
8. Click Add Users.
   
   
9. In Users/Groups, enter the user account.
   
   
10. Select Give users permission directly.
    
    
11. Click Full Control.
    
    
12. Click OK.
    
    

After you complete these steps, the user should be able to open the library, select the model, click the down arrow next to the model, and click Manage Model Item Security. When setting permissions on model items, follow these guidelines:

• For users who require broad access throughout the model (for example, to explore data and view clickthrough reports, or to design reports in Report Builder), grant permissions on the root node of the model.
  
  
• For users who require only limited access (for example, to view a report that contains data about the Contact entity), grant permissions on a specific entity or set of entities within the model hierarchy, but not on the root node itself.
  
  
• You must assign permissions on the root node for at least one user. You cannot save the model if the root node does not have read permissions for at least one user.
  
  

After you set model item security, users who have permission to load the model into Report Builder can create reports using the parts of the model to which they have access. Similarly, after the report is saved to a library, users can open the report and view data from the parts of the model to which they have access.

Users must have Open Items permission on a report and on any model that is used by the report. In most cases, users who have permission to access the SharePoint site will have this permission automatically. The Open Items permission is part of all predefined permission levels except Limited Access.

If the model is regenerated, you must reset the permissions. Regenerating a model will erase all permission settings within the model. Be aware that any user who has a Contribute level of permission, or Add Items permission, can regenerate the model. The user will not be warned about the potential loss of the security settings.

[Top]

The online help states that you can generate a model by using the Generate Model action on a shared data source (.rsds) file in a library. This information is incorrect. There is no Generate Model action.

To generate a report model from a SharePoint site, you must use the New | Report Builder Model command.

To use the New menu, you must first have registered the report server content types with the SharePoint library you are using before you generate a model.

1. Open the library that will contain the model file. On the library menu bar, you should see the following menus: New, Upload, Actions, and Settings. If you do not see Settings, you do not have permission to add a content type.
   
   
2. On the Settings menu, click Document Library Settings.
   
   
3. Under General Settings, click Advanced settings.
   
   
4. In the Content Types section, select Yes to allow multiple content types.
   
   
5. Change any other settings that you want, and then click OK.
   
   
6. Under Content Types, click Add from existing site content types.
   
   
7. In the Select Content Types section, in Select Site content types from, click the arrow to select Reporting Services.
   
   
8. In the Available Site Content Types list, click Report Builder Model, and then click Add to move the selected content type to the Content types to add list.
   
   
9. To add Report Builder Report and Report Data Source content types, repeat steps 4 and 5.
   
   
10. When you finish selecting all of the content types that you want to add, click OK.
    
    

A generated model always uses default settings and includes the entire schema of the data source upon which it is based. If you want a custom model, you must use another method to create the model. For more information, see "Ad Hoc Reporting with Report Models" in SQL Server Books Online. To generate a report model:

1. Open the library that will contain the model file.
   
   
2. On the Actions menu, click New.
   
   
3. Click Report Builder Model.
   
   
4. Enter a name for the model.
   
   
5. In Data Source Link, click the browse button to select a shared data source (.rsds) file. You can only select .rsds files. You must only select an .rsds file that defines a connection to a data source type that is valid for model generation. Supported data sources include SQL Server relational data sources, Analysis Services multidimensional data sources, and Oracle data sources.
   
   
6. Click OK. If the database schema is very large, model generation can take a long time. Model generation occurs on the report server. When model generation is finished, a new model item will appear in the library.
   
   

After you generate the model, you can subsequently regenerate it by pointing to the model, clicking the down arrow, and clicking Regenerate model.

[Top]

In Report Builder, a clickthrough report is a report that provides detailed information about the data contained within the main report. A clickthrough report is displayed when the Report Builder user clicks the interactive data that appears in the main report. These reports are automatically generated by the report server.

Instead of using the default single and multiple instance templates that the report server generates, you can create a report in Report Builder and use it as a customized clickthrough report. Then, you can link your report to the model as a single or multiple instance drillthrough report.

To map a report as a single instance clickthrough report, do the following:

1. If the library is not already open, click its name on the Quick Launch. If the name of your library does not appear, click View All Site Content, and then click the name of your library.
   
   
2. Point to the model for which you want to customize clickthrough reports.
   
   
3. Click the down arrow, and select Manage Clickthrough Reports.
   
   The Clickthrough Reports page appears.
   
   
4. Select the entity for which you want the clickthrough report to appear.
   
   

   Note:
   The primary, or base, entity used in the customized clickthrough report must to be the same entity as the entity you are selecting in step 4.

5. Click the Single Instance ellipsis (…) button.
   
   
6. Select the customized clickthrough report and click OK.
   
   

When a person views a report and clicks a single instance of the entity you selected in step 4, the customized clickthrough report appears.

To map a report as a multiple instance clickthrough report, do the following:

1. If the library is not already open, click its name on the Quick Launch. If the name of your library does not appear, click View All Site Content, and then click the name of your library.
   
   
2. Point to the model for which you want to customize clickthrough reports.
   
   
3. Click the down arrow, and select Manage Clickthrough Reports.
   
   The Clickthrough Reports page appears.
   
   
4. Select the entity for which you want the clickthrough report to appear.
   
   

   Note:
   The primary, or base, entity used in the customized clickthrough report must to be the same entity as the entity you are selecting in step 4.

5. Click the Multiple Instances ellipsis (…) button.
   
   
6. Select the customized clickthrough report and click OK.
   
   

When a person views a report and clicks multiple instances of the entity you selected in step 4, the customized clickthrough report appears now.

[Top]

When configuring SharePoint integration settings in SharePoint Central Administration, one step is to use the Grant Database Access page to grant SharePoint database access to the Reporting Services service accounts. If you subsequently change the service accounts used to run the Report Server Windows service or the Report Server Web service, you must repeat the configuration step. Similarly, if you add a SharePoint Web application to a server farm that is configured for report server integration, and that application is configured to run under a different user account than other applications in the farm, you must repeat the configuration step that grants database access to the report server accounts. After you reset the database access information, you should then restart the Windows SharePoint Services service to ensure that the old connection is no longer used.

1. In Administrative Tools, click SharePoint 3.0 Central Administration.
   
   
2. Click Application Management.
   
   
3. In the Reporting Services section, click Grant Database Access.
   
   
4. Click OK. The Enter Credentials dialog box appears.
   
   
5. Enter the credentials of a user who is a member of the Local Administrator's group on the computer that hosts the report server. The credentials will be used for a one-time connection to the report server computer for the purpose of retrieving service account information. The database login that is created for each service account will be updated in SharePoint databases.
   
   
6. To restart the service, click Operations.
   
   
7. In Topology and Services, click Services on Server.
   
   
8. For Windows SharePoint Services Web Application, click Stop.
   
   
9. Wait for the service stop.
   
   
10. Click Start.
    
    

[Top]

When creating a shared data source or modifying a custom report data source, one of the options that you can specify for the credential type is "Unattended report processing account". This option is equivalent to "None" or "No credentials" that you see in other Reporting Services tools that provide a user interface for specifying data source connection properties.

The unattended report processing account is used to connect to external servers when accessing data sources that do not process credentials (for example, XML data sources), performing unattended report processing, or retrieving external image files. When you select "Unattended report processing account", the report server will use the credentials of the unattended report processing to connect to an external computer, but they will not be passed to the target data source.

If you want to use the credentials to log in to a database, you must specify credentials in the connection string. You can specify Integrated Security=SSPI if the database server supports Windows integrated security and the account used for unattended report processing has permission to read the database. Otherwise, you must enter the user name and password in the connection string, where it appears in clear text to any user who has permission to edit data source connection properties.

Although you are not prevented from using the unattended report processing account to retrieve data after the connection is made, doing so is not recommended. The account is supposed to be used for very specific functions. If you use it to retrieve data, you undermine the purpose for which it is intended.

[Top]